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Control software analysis, Part I 
Open-loop properties 

Eric Feron * Fernando Alegre ^ 
September 29, 2008 



Abstract: As the digital world enters further into everyday life, questions 
are raised about the increasing challenges brought by the interaction of real-time 
software with physical devices. Many accidents and incidents encountered in 
areas as diverse as medical systems, transportation systems or weapon systems 
are ultimately attributed to "software failures" . Since real-time software that 
interacts with physical systems might as well be called control software, the 
long litany of accidents due to real-time software failures might be taken as 
an equally long list of opportunities for control systems engineering. In this 
paper, we are interested only in run-time errors in those pieces of software that 
are a direct implementation of control system specifications: For well-defined 
and well-understood control architectures such as those present in standard 
textbooks on digital control systems, the current state of theoretical computer 
science is well-equipped enough to address and analyze control algorithms. It 
appears that a central element to these analyses is Lyapunov stability theory, 
which translate into invariant theory in computer implementations. 

1 Introduction 

1.1 Preliminaries: An example system 

We consider a standard control system, in this case a one-mass, one spring 
system, such as that shown in Fig. [l] The system is modeled via the following 
differential equation 
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Figure 1: Controlled physical system 



In these equations, Xp and ip are measured in meters and meters per second, 
respectively, while u is expressed in Newtons. We assume that the output y is 
available for feedback purposes. The chosen controller is of the lead-lag type. 
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which guarantees good closed-loop system bandwidth (in excess of 20 rad/sec) 
and good steady-state disturbance rejection properties; following common prac- 
tices, the input to the controller y is first passed through a saturation function to 
avoid variable overflow in the controller. The essential properties of the closed- 
loop system may be easily extracted from the Bode plot of the open-loop transfer 
function of the plant mounted in series with the controller, shown in Fig. |2] For 
example, the phase margin can be easily seen to exceed 50 degrees. This con- 
troller is then implemented on a computer by considering a sample-and-hold 
architecture running at 100 Hz, by implementing the state-space model 
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Figure 2: Top: Bode plot. Continuous: loop gain of plant. Dashed: loop gain 
of plant + compensator. 



which is no more than a first-order Euler discretization of the following state- 
space realization of the controller ^ 
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In the expression for the compensator, is j/(0.01fc), the output of the system 
sampled at time O.Olfc. Likewise, Uk is the compensator output fed to the 
plant during the time interval [O.Olfc 0.01(fc-|- 1)), resulting in the closed-loop 
description of the system as shown in Fig. [3] This figure includes the sampling 
process S and the zero-order hold ZOH. An implementation of the compensator 
may then be realized by means of the simplified, but functional C code shown 
in Fig. |4j The final step involves the compilation of the C code to executable 
code, and the eventual operation of the system in closed-loop. 



1.2 Performance and stability questions 

Considering the entire system, made of the physical plant and its controller, we 
are led to asking whether "the system works" . In this paper, we are interested 
in asking this question about the software implementation of the control law 
shown in Fig. [4] and the corresponding executable binary code. 

Many control engineers and researchers may wonder whether this question 
makes any sense at all: After all, control system textbooks suggest that the 
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Figure 3: Closed-loop system 
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1: int main(int argc, char *argv[]) 
2: { 

3: double *x[2], *xb [2] , y, u; 

4: x[0] = 0; 

5: x[l] = 0; 

6: while(l){ 

7: fscanf (stdin,"%f ",&y) ; 

8: if (y >1){ 

9: y=l 

10: } 

11: if (y<-l){ 

12: y=-l 

13: } 

14: u = 564.48*x[0]-1280*y; 

15: fprintf (stdout, "7.f \n" ,u) ; 

16 : xb [0] =x [0] ; 

17: xb[l]=x[l]; 

18: x[0]:= 0.4990*xb[0]-0.0500*xb[l]+y; 

19 : X [1] : = . 01*xb [0] +xb [1] ; 

20: } 
21:} 



Figure 4: C implementation of controller 
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task of verifying whether the closed-loop system "works" amounts to establish- 
ing, in some way or some other, that the closed-loop "system" that consists of 
the system ([l]) combined with either the continuous-time controller ^ or the 
discrete-time controller ([S]) is stable, which requires no more than computing 
the roots of a low-order polynomial. Further, control systems manufacturers 
may require the controller itself to be open-loop stable. Other questions about 
system performance, including disturbance rejection properties and robustness 
against modeling inaccuracies, may also be easily answered by using algebraic 
or graphical methods. 

Note, however, that the process of generating C code from the continuous 
or discrete control laws is often done automatically, by means of commercial 
autocoders whose implementation details are not fully known. Likewise, propri- 
etary or public-domain compilers are then used to produce binary executables 
from the C code. While autocoders and compilers can be assumed to operate in 
good faith, they cannot just be trusted bhndly. In addition, the codes generated 
out of the specifications often contain detailed computations whose details are 
not known at the level of control law specifications. Thus the produced C code 
and the binary executable must be examined in detail for adequate performance 
by following a process that is independent from the original code generation pro- 
cess. The amount of work involved in such an endeavour may appear formidable. 
However, the alternative which is to certify the correctness of autocoders and 
compilers is even more daunting [R in99l IAR041 IRM99] . 

The rest of this paper is devoted to bringing forward the elements that make 
the static analysis of code that implements control system specification not only 
possible, but also necessary given how easy it is to perform. 

2 Code Analysis 

2.1 Performance analysis and Hoare logic 

Analyzing the software that implements a control system consists of answering 
several questions: 

• Does the control function keep executing properly and within acceptable 
execution time limits? 

• Is the implemented controller stable and what is the range of values ex- 
plored by each variable? 

• Is the closed-loop system stable? 

• Does the software implement the specifications? 

These questions may be extended to include further concerns about system 
performance. However, the problem remains fundamentally the same: That is, 
to reach the same level of confidence about system stability and performance 
when considering the controller code in Fig. H together with the plant (fT| as 
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that reached when analyzing the controller specification ([3]), together with the 
plant ([T|). To reach that goal, two options exist: 

The first option is to follow a "macroscopic pattern matching" approach, 
whereby the controller specification ^ is reconstructed from the code in Fig. [4] 
This solution, adopted in [CCF+OS,, .Fer^ . is particularly advantageous when 
the code structure is relatively repeatable from one instance to the other. How- 
ever, pattern matching can become more challenging if codes that implement 
controllers do not have well-identified and rigid structures. 

The second option, which we call code-level analysis, is to develop proofs 
that directly identify the code semantics. Code-level analysis is, in principle, 
supported by an elegant logical environment that closely matches available con- 
trol oriented methodologies. This environment, developed by Floyd and Hoare 
in the late 1960s |Flo67l lHoa69| . intends to describe the code semantics by con- 
catenating elementary knowledge about each line of code |PelOH Ch.7]: Each 
line of code is annotated with one precondition pre satisfied by the program state 
prior to the line execution, and one postcondition post satisfied by the program 
state after the execution of the line. Thus each line of code loc is transformed 
into a Hoare triple of the kind {pre}loc{post }, where the pre and post are 
compatible with loc. Global program properties can then be inferred by con- 
catenating Hoare triples, as follows: Considering two consecutive Hoare triples 
{pre-l}locA{post_l } and {pre-2}loc_2{post_2 } and the property {post_l} 
{pre-2}, whe have {pre_i}loc_l, loc_2{post_2 }. Further developments of Hoare 
logic will be used thereafter. 

2.2 Hoare logic and Lyapunov functions 

We now examine how Hoare logic can be used to formalize the analysis of control 
system stability requirements for the control system specifications and their 
implementation. Informally speaking, we know that the system that implements 
the controller is stable and all states are bounded because the matrix 

_ r 0.499 -0.050 " 
[ 0.010 1.000 

is stable, that is, its two eigenvalues have modulus less than one, and the input 
is effectively bounded in absolute value by one. While exact, this proof does 
not carry over easily to the software implementation. Moreover, it is some- 
what incomplete since it does not tell anything related to the range covered by 
the variables involved. These issues may be addressed by means of Lyapunov 
stability theory: Consider the Lyapunov function V{x) — Px, where 

_ r 0.0300 0.2000 
~ [ 0.2000 10.0000 

and P is a positive definite matrix. Then it is easy to show that the value of 
x'^Px decays along the trajectories of 

Xk+i = Axk, 
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1: A = [0.4990, -0.0500; 0.0100, 1.0000]; 

2: C = [564.48, 0] ; 

3: B = [1;0] ;D = -1280; 

4: X = zeros(2,l) ; 

5: while 1 

6: y = fscanf (stdin,"7.f ") ; 

7: y = max(min(y, 1) ,-1) ; 

8: u = C*x + D*y; 

9: fprintf (stdout,"7.f\n",u) ; 

10: X = A*x + B*y; 

11: end 

Figure 5: MATLAB implementation of controller 

that is V{xk + l) — V{xk) < if = and Xk 0. That alone indicates stability 
of the controller, yet it does not bring any indication about the size of the states 
of the system. For that purpose, and following well-known practices [BEFB94], 
it is possible to show that P defines not only a valid Lyapunov function, but 
also an invariant ellipsoid 

£p = {x e R2 I x'^Px < 1} . 

for any input y, and this ellipsoid defines a bounded region for Xk- In particular, 
if xq is included in £p (and it does since xq = 0), then the state will stay in the 
ellipsoid forever. A simple eigenvalue computation on P shows that each entry 
of the state x is bounded in absolute value by 7. 

Let us now examine how this knowledge can be included in the controller's 
executable code so as to establish the code's correctness. We may begin our 
effort with analyzing a Matlab script that implements the controller, given in 
Fig.|5] The reason for doing so is that a Matlab code structure is sufficiently close 
to typical control system specifications to make the correspondence between 
traditional proofs and code proof transparent, while remaining executable by 
Matlab's interpreter. Identifying x as the controller's state, we now proceed 
with establishing the stability of the controller's Matlab implementation by 
using Hoare logic. For that, we may begin the program annotation at any 
line of choice, for example at line 8: u = C*x + Dy. This assignment does 
not influence the state x but determines the value of u. It also introduces the 
controller input y. Thus we propose the following triple: 

{x££p, < 1} 

8: u = C*x+D*y; (4) 

{x £ £p, y^ < 1, < 2{CP-^C^ + D^)} 

Much about this statement may appear to be rather arbitrary at first sight, 
and indeed requires global knowledge of the program (or its specifications, de- 
scribed earlier) to be established. However, the statement {u^ < 2{CP~^C^ + -D^)} 
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can be easily figured out from the value of u and the statements {a: G f _p , < 1 } . 
From there on, it is possible to obtain statements about the evolution of the 
state-space by means of backwards propagation |Pel01| . To begin with, line 7: 
y = max(min(y , 1) ,-1) implicitly indicates that < 1 after this assignment, 
and can be commented via the triple 

{x e £p} 

7: y = max(min(y, 1) ,-1) ; 

{x e £p, < 1} 

At this point, the assignment in line 6: y = fscanf (stdin, "7of ") can 
simply be surrounded by the same statement {x e £p} to yield the triple 

{x e £p} 

6: y = fscanf (stdin, "y.f") 

{x e £p} 

Line 5: while 1 may not be separated from line 11: end. Following 
standard Hoare logic [PelOU IMon03| . these two lines may be documented as 
follows: 

{x e 8p} 

5: while 1 

{x e £p} 

{x e £p} 

11: end 

{false} 

Moving backwards, we see that the two lines that must be worked on are 
lines 4 and 10. Considering first the assignment 4: x = zeros (2,1), we are 
led to the triple 

{true} 

4: X = zeros(2,l) 
{x e £p}. 

Moving further backwards yields no changes concerning the state variable x, 
and triples may be constructed for lines 1 through 3 according to the template 

{true} 
loc 

{true}. 

Line 10 : x = A*x + B*y introduces the controller input y and performs 
an important transformation on the state x. Using insight from line 7 : y = 
max(min(y , 1) ,-1) we introduce the condition < 1. We also propagate the 
statement {x £ £p} backwards: Replacing x by its value Ax + By yields the 
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statement {Ax + By E £p}. Thus the triple 

{Ax + By e Ep, y^ < 1} 
10: X = A*x + B*y; 

{x e £p} 

Moving to line 9: f printf (stdout , "7of\n" ,u), we see that it really does 
not act in any way on the state of the program. However, it introduces the 
controller output value u, whose numerical range must be known. At this point, 
we postulate the property < 2{CP^^C^ + D^) and we are led to the triple 

{Ax + Bye £p, u2 < 2{CP-^C'^ + D^), < 1} 
9: fprintf (stdout, "7.f\n" ,u) 
{Ax + Bye£p, y2 < l}. 

For this triple to be "compatible" with the triple Q associated with line 8, 
we must prove the statement 

{x e £p, < 1} =^ {Ax + By eSp, y^ < l} ■ (5) 

For the specific instances of A, B and P under consideration, this statement is 
indeed true, yet not trivial. A simple proof relies on the 5-procedure |AG64j . 
which amounts to introducing the auxiliary (and true) statement 

V(a;, y) {Ax + ByfP{Ax + By) - O.Olx'^Px - 0.99y^ < 0. (6) 

leading to 

{x e £p, y^ < 1, {Ax+By f P{Ax+By)~Omx^ Px~0.99y^ <0}=> {Ax + By e Ep, y^ 

which may now be checked much more easily than (jsj) alone. Thus a preferrable 
triple for line 8 is 

{x £ £p, 2/2 < 1} 
8: u = C*x+D*y; 

{x e Ep, < 1, 

{Ax + ByYP{Ax + By) - Q.Qlx^Px - 0.9V < 0, < 2{CP-^C'^ + D^)] 

Concatenating statements about all individual instructions together leads us 
to the following annotated Matlab code: 
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{true} 

1: A = [0.4990, -0.0500; 0.0100, 1.0000]; 

{true} 

2: C = [-564.48, 0] ; 

{true} 

3: B = [1;0] ;D=1280 

{true} 

4: X = zeros(2,l) ; 

{x e £p} 

5: while 1 

{x e £p} 

6: y = fscanf (stdin,"y.f ") 

{x e £p} 

7: y = max(miii(y , 1) ,-1) ; 

{xe£p, < 1} 

8: u = C*x+D*y; 

{x e £p, < 1^ 

{Ax + By)^P{Ax + By) - Q.Qlx^Px - 0.992/2 < 0, < 2{CP-'^C'^ + D^)} 
skip 

{Ax + Bye £p, < 2{CP-^C^ + D^), y^ < 1} 

9: fprintf (stdout, "°/.f\n" ,u) 

{Ax + Bye£p, < 1} 

10: X = A*x + B*y; 

{a; e £p} 

11: end 

{false} 

This annotated program contains the instruction skip whose purpose is only 
to separate two consecutive logical statements. 

3 Forward vs. backwards propagation of con- 
straints 

Although the backwards constraint propagation described in the previous sec- 
tion is easy to do and best matches the well-known procedures used to establish 
stability properties of dynamical systems, forward constraint propagation pro- 
vides key insights about how these constraints may otherwise be formulated. 

We now reconsider the Matlab code shown in Fig. |5j with a forward explo- 
ration perspective. Once again, ellipsoids are used to bound all state variables 
and inputs involved in this program. Forward propagation allows us to begin 
at line 1: A= [0.4990, -0.0500; 0.0100, 1 . 0000] , which can simply be 
surrounded by {true} statements to produce the Hoare triple 
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{true} 

1: A = [0.4990, -0.0500; 0.0100, 1.0000]; 
{true} 

Lines 2 and 3 can be treated similarly. Line4: x = zeros (2, 1) introduces 
the variable x, and since x = 0, line 4 can be followed by the post-condition 
{x £ £p} to yield the triple 

{true} 

4: X = zeros (2,1) ; 
{a; e £p} 

which is the same as that given in the backwards analysis. Lines 5 and 11 

introduce the controller loop, and wc postulate the pre-condition {x € £p}, 
which then leads to commented set of commands: 

{x e £p} 

5 : while 1 

{x e £p} 

{x G £p} 
11: end 
{false} 

Line 6 : y = f scanf (stdin, "7of ") ; merely introduces the variable y with 
no particular property associated with it. Thus the triple 

{x e £p} 

6: y = fscanf (stdin,"y.f ") ; 

{x e £p} 

The next line 7: y = mcLx(inin(y , 1) ,-1) ; is much more informative since 

it forces y to be bounded by one in absolute value. This information may 
be encoded in various ways. One is to incorporate this information verbatim, 
therefore leading to the triple 

{x e £p} 

7: y = max(min(y, 1) ,-1) ; 

{x e £p. < 1} 

However, the postcondition {x e £p, y^ < 1} will not be used as the 
preconditon for line 8: u = C*x + D*y;. Instead, we introduce the weaker 
pre-condition 



Asking what the precondition becomes after passing through line 8 is equivalent 
to asking what the image of an ellipsoid through a linear mapping is. Since it is 



& £q? , with Q 



O.OIP 





0.99 
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also an ellipsoid (in this case 1-dimensional) , we conclude that a valid clause in 
the postcondition of line 8 is u < [C D] Q-i [C DY , while keeping the other 
clausal elements identical. The resulting triple is therefore 



X 

y 

u 

X 

y 



-- C*x + D*y; 

g£q, < [CD]Q-^[CDf 



which propagates the set to which x and y belong, while providing a bound on 
the output variable u. Line 9: f printf (stdout , ""/f \n" ,u) ; merely writes 
the output of the controller to the appropriate memory location for further 
processing. Since u is not used afterwards, its range may be dropped from the 
postcondition, thus leading to the triple 



9: fprintf (stdout, "7.f\n" ,u) ; 

X 

y 



We finally consider line 10: x = A*x + B*y. Again, this line transforms 
the ellipsoid £q into the ellipsoid Sp, where 



P = 



1 



1 



0.01 0.99 

To conclude, thus line 10 leads to the following triple 



(7) 



y 



10: X = A*x + B*y; 

{x e £p} 

The documentation of the program by means of Hoare triple is now complete. 
It is necessary, however, to check that the post condition of line 10 implies the 
precondition of line 11, that is: 



{x e £p} 
This is equivalent to showing that 



{x e £p}. 



0.01' 



-AP-'A^ 



0.99 



-BB^ 



P < 0, 



(8) 



which is indeed true for the given values of A, P and B. Moreover, it can 
be shown that the clause Q is equivalent to ([6 | for g eneric values of A, B, 
and P, using standard matrix manipulations [BEFB94], thus demonstrating 
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the "equivalence" of the forward and backwards approaches to analyze this 
program. The forward analysis eventually yields the annotated program 

{true} 

1: A = [0.4990, -0.0500; 0.0100, 1.0000]; 

{true} 

2: C = [-564.48, 0] ; 

{true} 

3: B = [1;0] ;D=1280 

{true} 

4: X = zeros(2,l) ; 

{x e £p} 

5: while 1 

{x G £p} 

6: y = fscanf (stdiii,"y.f ") 

{x e £p} 

7: y = max(min(y, 1) ,-1) ; 

{x e £p, y2 < 1} 
skip 

X 



y 



8: u = C*x+D*y; 



y 



eSg, < [C D]Q-^[C DY 



9: fprintf (stdout, "7,f\ii" ,u) 

X 



y 



10: X = A*x + B*y; 

{x e £p} 
skip 

{x e £p} 
11: end 



4 C code analysis 

The latter analysis may now be extended to the original C code given in Fig. |4] 
The main difference between the C code and its Matlab counterpart is the level 
of detail reached by the instructions; while Matlab uses vectors, matrices, and 
direct operations on these, the C program only performs scalar operations. In 
addition, some 1-line functions now extend over several lines. It is therefore 
interesting to see how the proofs developed for the earlier Matlab code apply to 
this more detailed C code. 
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4.1 ForwEird analysis 

Wc will perform only the forward analysis for the sake of brevity. Skipping 
variable declarations, the first relevant line of code is 4: x[0]=0. We may 
therefore write the triple 

{true} 

4: x[0] =0 

{x[0] = 0} 

Line 5 : x[l] = completes the initialization of a; = [x[0] x[l]]^, leading to 
the triple 

{x[0] = 0} 

5: x[l] = 

{x e £p}. 

Doing as precedently, line 6: while (1){, together with line 20: } leads 
to the set of commented lines 

{x € Sp} 
6: while(l){ 
{x e £p} 



{x e Sp} 

20: } 
{false} 

Line 7: f scanf (stdin, "\y,f " ,&y) ; likewise leads to the triple 

{x e £p} 

7: f scanf (stdin, "V/,f",&y) ; 

{x e £p}. 

The test 8: if (y >1){ . . . 10: } may be commented using insight from 
line 9 as 

{x e £p} 

8: if (y >1){ 

{x e£p,y> 1} 

{x e£p, y= 1} 
10: } 

{x e £p, y <= 1}. 
which is of course compatible with the assignment 9 : y = 1 
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{x G£p, y> 1} 

9: y = 1 

{x e£p, 1}. 

The second test 11: if (y<-l){ ... 13: } is documented the same way 

{x e £p, y <= 1} 

11: if (y<-l){ 

{x eSp, y< -1} 



{x e£p, y = -1} 
13: } 

{x e £p, y2 < 1 

and hne 12: y=-l yields the triple 

{x ££p, y< -1} 

12: y=-l 

{x e£p, y = -1}. 

The latter postcondition is clearly the same as that of line 7 of the Matlab 
program shown in Fig.jsj Following the same process as for the Matlab program, 
the precondition for line 14 : u = 564 .48*x [0] -1280*y is chosen to be weaker 
than the post-condition of line 13; we choose the precondition 



X 

y 



&£c 



with Q = 



O.OIP 
0.99 



to generate the triple 



{ 


X 




. y . 


14 


: u 


{ 


X 




. y . 



Line 15: 
the triple 



e£Q, <[C D]Q-^[C Df^ 
f printf (stdout , "°/of \n" ,u) ; may in turn be instrumented as 



15: fprintf(stdout,"%f\n",u); 

X 



y 

Lines 16 and 17 utilise a buffer variable aimed at performing the controller 
state update. The effect of these lines is easier to figure out by means of ma- 
trix operations: For example, line 16: xb[0]=x[0] can be seen as the matrix 
operation 



16 



X 

y 

xb[l] 



1 

1 

1 

10 



X 

y 



Given this matrix operation, it is easy to figure out the image of the ellipsoid 
£q through this mapping. The parameterization of the resulting ellipsoid needs 
changing, however, because it is singular (it is flat along one of its semi-axes). 
Whenever the matrix R is invertible, the following define the same ellipsoid: 



{x I x'^R-^x < 1} = |a 



1 

X 



X 

R 



> 



When R is not invertible, then only one of the statements above defines an 
ellipsoid. For the sake of conciseness, we will name Qr the ellipsoid defined as 



Gr 



1 

X R 



> 



With such an alternative ellipsoid definition we may write a concise triple 
for line 16 as 



X 

V 



16: xb[0]=x[0] 



X 

y 

xb[l] 



with 



" 1 





" 




' 1 





' 
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1 











1 
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1 










1 









R 



Line 17: xb[l]=x[l] ; may be treated likewise, and yield the triple 
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where 



10 
10 
10 
1 
10 



R 



10 
10 
10 
1 
10 



and xb — 



xb[l] 
xb[2] 



Continuing along the same lines the triple for 18: x[0] := 0.4990*xb[0]-0.0500*xb[l]+y; 





X 


1 


y 




xb 


18 


X 




X 


1 


y 




xb 


with 



&Qs 



€ Qt 



T ^ 



1 0.4990 -0.0500 

10 

10 

1 

1 



s 



1 0.4990 -0.0500 

10 

10 

1 

1 



and the triple for line 19: x[l] := . 01*xb [0] +xb [1] ; is 



f 


X 






y 






xb 





19 : X [1] : = . 01*xb [0] +xb [1] ; 

{x G Gu} 

with 



U 



1 
0.01 1 



T 



1 
0.01 1 



Explicit calculations then show U^^ > P, which ensures consistency between 
the postcondition of line 19 and the precondition of line 20. Moreover, it is easy 
to show that U = P^^ , where P is defined in Eq. ill. 



4.2 Remarks 

Bringing the forward analyses of the Matlab code, on the one hand, and of the 
C code, on the other hand, shows how the higher level-of-detail present in the C 
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code instructions yields considerably more detailed information about the be- 
havior of each variable. This hgher level of detail is precisely what makes the 
analysis of the C code necessary beyond that of the Matlab code. The C code 
analysis is, however, not complete and still contains ambiguities. Consider for 
example Line 18: x [0] : = . 4990*xb [0] -0 . 0500*xb [1] +y ; . Depending on 
the compiler used, this line may be executed as x [0] : = (0 . 4990*xb [0] + (-0 . 0500*xb [1] +y) ) ; 
or X [0] : = ( (0 . 4990*xb [0] -0 . 0500*xb [1] ) +y) ; , for example. The resulting in- 
termediate values may differ widely, yet must be computed in advance to offer 
a complete analysis of the real time computations that take place during com- 
ntroUer operations. This justifies a further, more detailed analysis of the code 
that is produced by compiling that given in Fig. [4j 

In addition, it is clear that the analyses shown on a simple second-order 
controller example easily extend to linear controllers of arbitrary order (possibly 
subject to input saturation). 



5 Conclusions 

In the first part of this report, we have advocated the necessity of documenting 
not only the specifications, but also the implementation of control systems. 
Using well-known proofs about the behaviors of controller specifications, we 
have shown how such proofs may be translated as proofs about various levels of 
implementation of such controllers. 
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